G-gen の min です。Google Apps Script（以下、GAS）で開発したアドオンをユーザーが実行した際、スクリプトプロパティの読み取り時に PERMISSION_DENIED エラーが発生しました。本記事では、この事象の原因と対処法を解説します。 事象 原因 対処法 定数としてコード内に記述する ユーザーにスクリプトファイルへの閲覧権限を付与する 事象 GAS で作成した機能を Google Workspace アドオンとして配布し、利用者がそのアドオンのメニューを実行した際、以下のようなエラーログが Google Cloud の Cloud Logging に記録され、処理が失敗しました。 { " insertId ": " -w58fk8fbk0qfb ", " jsonPayload ": { " message ": " ストレージからの読み取り中にサーバーエラーが発生しました。エラーコード: PERMISSION_DENIED。 ", " serviceContext ": { " service ": " AKfycbw...（省略）... " } } , " resource ": { " type ": " app_script_function ", " labels ": { " project_id ": " 000000000000 ", " invocation_type ": " menu ", " function_name ": " callUpdateMasterData " } } , " severity ": " ERROR ", " labels ": { " script.googleapis.com/deployment_id ": " AKfycbw...（省略）... " } } メインのエラーメッセージは、以下のとおりです。 ストレージからの読み取り中にサーバーエラーが発生しました。エラーコード: PERMISSION_DENIED。 該当のスクリプトでは、 PropertiesService.getScriptProperties().getProperty('KEY_NAME') メソッドを使用し、GAS エディタ上で手動設定した スクリプトプロパティ を読み取ろうとしていました。 該当のソースコード const TARGET_URL = PropertiesService . getScriptProperties () . getProperty ( 'TARGET_URL' ) ; function callUpdateMasterData () { // ...処理... // URLにアクセスしてデータを取得する const response = UrlFetchApp . fetch ( TARGET_URL ) ; // 結果をログに出力する Logger . log ( 'Response Code: ' + response . getResponseCode ()) ; } スクリプトプロパティ 原因 このエラーは、Google Workspace Marketplace で配布されるアドオンのセキュリティ仕様と、スクリプト実行環境の関係に起因しています。 Google Workspace アドオンでは、スクリプト実行ユーザーの環境で処理が実行されます。しかし、スクリプトプロパティは「スクリプトプロジェクト（ファイル）に紐づく共有ストレージ」であり、 そのファイルにアクセス権を持つユーザー間で共有 されるものです。 Marketplace 経由で配布されたアドオンを使用する場合、実行ユーザー（アドオン利用者）はスクリプトプロジェクト自体の所有者や編集者ではありません。 ユーザーには、開発者の Google ドライブ内にある GAS プロジェクトファイル自体へのアクセス権限がないため、結果としてそのファイルに付随するプロパティストアへのアクセスも拒否されます。 PropertiesService.getScriptProperties() を用いた読み取り処理が、実行時に PERMISSION_DENIED エラーとなります。 参考 : プロパティ サービス 対処法 定数としてコード内に記述する 外部サービスの URL や固定の ID など、公開されても問題ない設定値であれば、スクリプト プロパティではなくコード内の定数（ const ）として記述することでエラーを回避できます。 // 修正前：スクリプトプロパティから読み取る（アドオン配布時にエラーになる） // const TARGET_URL = PropertiesService.getScriptProperties().getProperty('TARGET_URL'); // 修正後：コード内に定数として定義する const TARGET_URL = 'https://blog.g-gen.co.jp/' ; function callUpdateMasterData () { // ...処理... // URLにアクセスしてデータを取得する const response = UrlFetchApp . fetch ( TARGET_URL ) ; // 結果をログに出力する Logger . log ( 'Response Code: ' + response . getResponseCode ()) ; } ただし、 API キーなどの機密情報 はソースコード内に直接記述してはいけないことに十分留意してください。 ユーザーにスクリプトファイルへの閲覧権限を付与する アドオンの実行ユーザーに対して、実体となる GAS プロジェクトファイルの 閲覧者権限 を付与します。 スクリプト プロパティはファイルに紐づくメタデータであるため、ユーザーがファイル自体へのアクセス権を持っていれば、プロパティの読み取りが可能になります。 ただし、この方法は ユーザーがソースコードを閲覧可能になる というセキュリティ上の懸念があります。社内用ツールなど、ソースコードの内容が利用者に公開されても問題ない場合にのみ採用してください。 佐々木 愛美 (min) (記事一覧) クラウドソリューション部 データアナリティクス課。2024年7月 G-gen にジョイン。G-gen 最南端、沖縄県在住。最近覚えた島言葉は、「マヤー（猫）」。

はじめに エンジニアの方もエンジニアではない方も、こんにちは。これまでは金融業界で SRE としてGoogle CloudのプロジェクトにJoinしていましたが、最近プロジェクトが変わり、Amazon Web Services (AWS) に挑戦しています。 先日はGoogle Cloud Partner Top Engineer 2026 に選出していただきました！ みなさんは普段、どのようなインプットをしていますか？ 私は「自分から情報を収集しなくても、自動で技術情報が目に入る仕組み」としてRSSを使っています。RSSを利用するには主にRSSリーダーを利用することが多いかと思いま

こんにちは。BIGLOBEでSalesforceを利用した業務アプリケーション開発を担当している藤田です。 現在、BIGLOBEの開発チームでは「開発スピード2倍」を目標に掲げ、システム刷新や改善活動に取り組んでいます。 Salesforce開発に携わっている方なら共感していただけると思いますが、Salesforceはローコード/ノーコードの強みを活かし、画面上で設定を「ポチポチ」していくだけで素早く動くアプリケーションを作れるのが魅力のひとつです。 しかし、 「作るのは簡単だが、その変更点を設計書に反映する作業が非常に面倒」 という悩みはありませんか？ 実装スピードが上がれば上がるほど、ドキュメントの更新が追いつかなくなったり、転記ミスが発生したりしがちです。 そこで私たちは、Salesforceが提唱する 「ソース駆動型開発（Source-Driven Development）」 の考え方を取り入れ、Salesforce上のデータ（メタデータ）から設計書を逆生成することに挑戦しました。今回はその一例として、バッチ一覧を自動生成する仕組みをご紹介します。 システム構成：Salesforce CLIをドキュメント生成に応用する 実践：バッチ一覧の自動生成 こだわりの「リンク機能」 導入効果と今後の展望 まとめ システム構成：Salesforce CLIをドキュメント生成に応用する BIGLOBEでは、設計書をGoogleスプレッドシートで管理しています。そのため、Salesforceから取得した情報を最終的にスプレッドシートへ流し込むことがゴールとなります。 構築した自動化フローの全体像は以下の通りです。 １．データ取得（Node.js & Salesforce CLI）: まず開発PC上でNode.js製の自作プログラムを実行します。ここでポイントとなるのが、Salesforce CLI (SFDX) の活用です。これは本来、Salesforceが推奨するソース駆動開発においてデプロイ等に使われるコマンドラインツールですが、今回はこれを介してSOQLを実行し、必要な定義情報をデータとして取得しています。 ２．中間ファイル生成: 取得したデータを加工し、TSVファイルとしてGoogleドライブに保存します。 ３．反映: Googleスプレッドシートに仕込んだGoogle Apps Scriptを実行（ボタンポチ）し、ドライブ上のファイルを取り込んでシートに展開します。 実践：バッチ一覧の自動生成 具体的な活用例として、「フローバッチの一覧」を生成するケースを紹介します。 Salesforceにはバッチ実行の方法がいくつかありますが、今回は「Scheduled（スケジュール済み）」タイプのフローを取得対象としました。Node.js側のツールでは、以下のようなSOQLを発行してフローの定義情報を取得しています。 SELECT Id, FlowLabel, ApiName, Description, Type FROM FlowRecord WHERE Type = 'Scheduled' SELECT Id, CronJobDetail.Name, CronJobDetail.JobType, State, NextFireTime, PreviousFireTime, StartTime, CronExpression FROM CronTrigger WHERE CronJobDetail.JobType IN ('6','7') このようにメタデータへ直接クエリを投げることで、正確な定義情報を取得できます。これらを組み合わせ、スプレッドシートに出力した結果がこちらです。 バッチ名（論理名・物理名）やCRON形式の実行スケジュールが一目でわかるようになりました。 こだわりの「リンク機能」 この自動化において、開発者体験（DX）を向上させるために工夫したのが 「実装画面への直リンク」 です。 出力結果のB列にはURLが生成されており、ここをクリックするだけでSalesforce上の該当フローの実装画面へ即座にジャンプできます。ソースコード管理のアプローチを取り入れつつも最終的な確認は人間が行うため、設計書と実環境をシームレスに行き来できるこの機能は非常に便利です。 導入効果と今後の展望 今回紹介したバッチ一覧以外にも、同様の仕組みを使ってオブジェクト定義一覧やレポート一覧なども自動生成しています。 手作業での更新を廃止したことで、設計書の記述ミスがなくなり、常に最新の実装状態がドキュメントに反映されるようになりました。なにより、エンジニアが「文書作成」という非生産的な時間から解放され、より本質的な開発業務に集中できるようになったことが最大の成果です。 また、今後はこの機能を応用して 本番環境と開発環境のデータを取得・比較し、リリース前の変更箇所を洗い出す「環境間の差分チェック」 にも役立てていきたいと考えています。さらにはこれをCI/CDパイプラインの一部として組み込み、ソースコードレベルでの変更管理を徹底することで、より堅牢なDevOps体制を築いていきたいと思います。 まとめ BIGLOBEでは、このように「開発スピード2倍」という目標に向け、開発プロセスそのものの改善にも積極的に取り組んでいます。 Salesforce開発というと、SaaSの標準機能の枠組みの中での作業と思われがちですが、弊社ではCLIやスクリプト言語を組み合わせ、 「自分たちの開発環境は自分たちでコードを書いて良くしていく」 というエンジニアリング文化を大切にしています。 今後も、新しい技術やアイデアを積極的に取り入れながら、より効率的な開発環境を目指して改善活動を続けていきます。